The technology empowering large-scale mobile network communications has improved dramatically in recent years. Users of mobile stations may now not only make standard telephone calls via a cellular network, but may access a wide variety of voice and data services including email applications and the downloading of audio, video, and multimedia presentations. Many of these services are delivered using a packet-switching IP (Internet protocol) network that is connected to the cellular network via a gateway. Other types of mobile devices, such as laptop computers, may also access these services via, for example, a WLAN (wireless local area network). Given the multiplication of available applications, new network architectures have been developed to facilitate delivery of these services.
Many communication network components are configured and operated according to standard protocols that are being developed and promulgated by standard-setting bodies having a diverse membership. On such group is the 3GPP (3rd Generation Partnership Project). 3GPP, for example, has promulgated standards for a new network architecture known as IMS (IP Multimedia Subsystem). IMS is an architectural framework for delivering multimedia content for mobile users. This architectural framework is directed to session and connection control services as well as application services. It is an effort to collectively define all IP-based wireless services such as voice and data as well as signaling and control. A brief overview of an IMS network follows.
FIG. 1 is a simplified block diagram illustrating a network 100 including selected components related to operation of an IMS, in which embodiments of the present invention may be advantageously implemented. Network 100 includes an AS (application server) 105 connected to application 110 and HSS (home subscriber server) 105. Application servers provide services related to IMS communications and interface with the applications 110 themselves. Note that although this depiction of the IMS architecture shows a single AS and application, in reality of course there are many such devices in the communication network. The HSS 115, typically associated with a mobile user's home network, maintains information useful to the IMS such as subscriber profiles and current location. These components are considered to be part of the application and services layer of the IMS architecture.
The application and services layer interfaces with an IMS layer using SIP (session initiation protocol) control signaling. Specifically, the AS 105 and the HSS 115 communicate with the CSCF (call session control function) 120 to perform such functions as setting up and terminating communication sessions. CSCF 120 is part of the IMS layer, and is actually representative of the P-CSCF (proxy-CSCF) 122, the ICSCF (interrogating-CSCF) 124, and the S-CSCF (serving-CSCF) 126. Generally speaking, the S-CSCF 122 interfaces directly with the AS 105, while the P-CSCF 126, which may be in a user's home network or in a visited network, is the proxy server that initially directs user call toward their target destination. Also shown in the IMS layer of FIG. 1 is a BGCF (breakout gateway control function) 125, which allows the IMS to communicate with circuit switched networks (not shown).
The access layer of an IMS network enables mobile users to access the services offered via the IMS. In FIG. 1 the access layer is represented by access networks 130, which include for example the cellular networks and WLANs referred to above. Access networks 130 typically interface with the CSCF 120 via a packet-switching IP network (not shown). Representing the transport layer in the simplified block diagram of FIG. 1 is MRF (media resource function) 135, which comprises MRFC (media resource function controller) 137 and MRFP (media resource function processor) 139. MRFC 137 interfaces with the CSCF 120 and controls the operation of MRFP 139. MRFP 139 handles, for example, the manipulation of streaming audio and video multimedia presentations.
As mentioned above, FIG. 1 is a simplified block diagram depicting generally the relationships and function of selected IMS components. The present invention relates to the signaling, and in most implementations specifically the SIP control signaling that takes place between IMS entities such as those shown in FIG. 1. An overview of that signaling process will now be described as well.
FIG. 2 is a message flow diagram illustrating an exemplary SIP signaling sequence 200 according to the present state of the art. The signaling sequence is a series of control messages passing between a number of network components. Here the network components participating in the signaling sequence are a UA (user agent) 205, a first proxy server 210, a first AS 215, a second proxy server 220 and a second AS 225.
In this example, the signaling sequence relates to establishing and later terminating a connection between UA 205 and second AS 225. To establish the connection, the UA 205 first sends an INVITE request to the first proxy server 210, which forwards the request to first AS 215, setting up the dialog 1. A dialog is a communication session between two peer devices, in the case of dialog 1 between UA 205 and AS 215. (Proxy server 210 functions as a switch that forwards messages from one peer device to another, or to another proxy server on their way to the second peer device.) Similarly, first AS 215 and second AS 225 set up dialog 2 between themselves when the INVITE request is sent in a message from AS 215 to proxy server 220 and a message from proxy server 220 to AS 225.
As can be seen in FIG. 2, AS 225 returns several responses, basically in reply to the message from proxy server 220 relaying the INVITE request originating at UA 205. The first response is TRYING, which is related from AS 225 to UA 205 in a series of messages between each of the participating nodes. In this example, the TRYING response is followed by RINGING, and finally an OK response. In SIP, the OK response is a 2xx type of message (more specifically, 200—OK), which indicates a request has been successfully completed. The messages of dialog 1 and dialog 2, up to this point, are referred to, respectively, as transaction 1 and transaction 2. IN SIP, a transaction consists of a single request and any responses to that request. Note that in FIG. 2, an ACK (acknowledgement) was subsequently also sent, in a series of messages from UA 205 to AS 225. By convention, however, SIP transactions include only those messages up to a 2xx response (if one occurs, as it does in the example of FIG. 2).
In the example of FIG. 2, the communication session continues until it is terminated by a BYE message, in this case originating at AS 225 and relayed in a series of messages between participating nodes back to UA 205. The BYE messages initiate, respectively, transaction 3 between AS 225 and AS 215 (which is therefore part of dialog 2) and transaction 4 between AS 215 and UA 205 (forming a part of dialog 1). UA 205, in response, initiates its own OK message and it is similarly sent through each node to UA 225. This OK response terminates transaction 3 and transaction 4. In this example, it also terminates dialog 1 and dialog 2, and as a consequence marks the end of SIP signaling sequence 200.
Although the IMS architecture using SIP protocols has many advantages, the use of separate dialogs and transactions within a given signaling sequence poses problems for efficient fault localization and troubleshooting in the event that the communication session is not established or terminated successfully. The segmented nature of the signaling sequence is further illustrated with reference to FIG. 3.
FIG. 3 is a simplified block diagram illustrating an exemplary IMS control message flow 300 for an IMS call according to the present state of the art. The configuration of the participating nodes is similar though not identical to that of the example shown in FIG. 2. In FIG. 3, UA 305 forms a dialog 1 with AS 320 via a first SIP proxy server 310 and a second SIP proxy server 315. Likewise UA 340 forms a dialog 3 with AS 325 via a third proxy server 335 and a fourth proxy server 330. Dialog 2 in this example includes the second proxy server 315 and the fourth proxy server 330 as well as the first AS 320 and the second AS 325. Note that instead of as 320 and 325, any type of UA might be substituted. First proxy server 310 and third proxy server 335 may be, for example, P-CSCFs, and second proxy server 310 and fourth proxy server 330 may be, for example S-CSCFs. Other components may also be present as well. As with the previous example, the configuration of FIG. 3 uses three separate SIP dialogs to form a communication session between the end UAs, UA 305 and UA 340. Again, this environment can make fault localization and other troubleshooting less efficient and effective than is often desirable.